home *** CD-ROM | disk | FTP | other *** search
/ GIFs Galore 1993 September / Walnut Creek GIFs Galore CDROM WIN-MAC (Walnut Creek CDROM)(September 1993).iso / pc / macutils / misc / tar / suntar2 / speed_te.sts < prev    next >
Text File  |  1993-12-28  |  8KB  |  198 lines
  1.  
  2. Times (in seconds) on a Macintosh LC with 40MB hard drive (access time 26 msec)
  3. When not specifed, the times are with almost all INITs disabled
  4. (there where only a couple which load themselves before the INIT manager
  5. and SuperClock, which was used to measure speeds by subtracting the
  6. initial and final times)
  7.  
  8. ÑÑÑÑun-BinHex (ram disk -> hard disk, 900k file)
  9.  
  10. suntar 1.1  (.hqx.tar)  210 sec (the slowest unBinHexer in the world...)
  11. deHQX 2.0                150 sec  (ram-ram) 175 sec (HD->HD) 
  12. Stuffit 1.5.1        146 sec
  13. suntar 1.2.1         137 sec            (I carefully optimized the algorithm, but unfortunately
  14.                                 that was not the bottleneck)
  15. Stuffit Deluxe 3.0.6    125 sec
  16. Downline    1.1     125 sec
  17. BinHex 4.0              90 sec
  18. Compact Pro 1.3.3    49 sec (with or without INITs: no event handling, no background
  19.                             operation, the Macintosh does nothing else until the extraction
  20.                             finishes: I never liked this way to speed up an application)
  21. suntar 1.3.3        43 sec (48 with INITs)    (introduced disk buffering, and the
  22.                         optimizations introduced in 1.2 may now show their strength)
  23. BinHqx DA (32k buffer size)        36 sec (38 with INITs)
  24. suntar 2.0            33 sec    (36 with INITs)       (uses a look-up table to compute the
  25.                                         CRC error checking: pole position !!!)
  26.                                 
  27. ÑÑÑÑcompressed PackIt extraction (ram disk -> hard disk, 900k file)
  28.  
  29. PackIt III                    315 sec (320 sec with INITs)
  30. suntar 1.2.1      156 sec  (175 sec with INITs)
  31. Stuffit Deluxe 3  130 sec
  32. Stuffit 1.5.1        120 sec
  33. unpit 0.1                    105 sec
  34. unpit 0.3 (compiled with Think C 5, I had the source but could not find the application)
  35.                   100 sec
  36. suntar 1.3.3      88 sec        (no change to the algorithm, but benefits from I/O buffering)
  37. suntar 2.0 beta 8   66 sec    (uhh, in suntar 1.3 I'd forgotten to fully enable buffering !
  38.                             And obviously the faster CRC routine helps)
  39. suntar 2.0        42 sec    (optimized the routine: it's not nice being
  40.                             proud of something which I knew was not the
  41.                             best I could do)
  42.  
  43. ÑÑÑÑnon-compressed PackIt extraction (ram disk -> hard disk, 900k file)
  44.  
  45. PackIt III             225 sec
  46. suntar 1.2.1   100 sec
  47. StuffIt 1.5.1   65 sec
  48. StuffIt Deluxe 65 sec
  49. suntar 1.3.3    40 sec
  50. unpit 0.1                29 sec
  51. unpit 0.3                28 sec
  52. Downline       23 sec
  53. suntar 2.0 b8  18 sec       (the gain from 1.3.3 to 2.0 b8 is 22 sec: same file, same gain)
  54. suntar 2.0     12 sec
  55.  
  56. ÑÑÑÑtar extraction (floppy disk->ram disk, a directory with many files,
  57.     end of archive at sector 2556)
  58.  
  59. suntar 1.1      140 sec  (187 with INITs)
  60. suntar 1.2.1   140 sec  (185)
  61. StuffIt Deluxe (.tar file on a HFS floppy)  75 sec (+16 for reading
  62.     the directory + the time to select all the files in the scrolling list)
  63. tar 3.0                51 sec     (59)
  64. suntar 2.0   51 sec     (58)        (the accuracy of measurements can't guarantee a
  65.                                     1 sec difference but suntar 2.0 performs some tests
  66.                                     to identify long pathnames and it is reasonable
  67.                                     to expect a small speed decrement over 1.3.3)
  68. suntar 1.3.3 50 sec        (56)
  69.  
  70. (suntar 2.0: save sectors 0 to 2556 36 sec, Copy disk archive to file 47 sec)
  71.  
  72. ÑÑÑÑtar extraction (file on hard disk->ram disk, 2556 sectors archive)
  73.  
  74. suntar 1.1   96 sec   (138 sec with INITs)
  75. suntar 1.2.1 92 sec      (135 sec)
  76. StuffIt Deluxe 3.0.6   30 sec (33 with INITs) (+5 to read the directory)
  77. suntar 1.3.3 22 sec        (28)
  78. suntar 2.0   22 sec     (27)
  79. tar 3.0      18 sec     (21)
  80.  
  81. ÑÑÑÑtar extraction (HD->HD, 900k file)
  82.  
  83. suntar 1.1       92 sec
  84. suntar 1.2.1    90 sec
  85. untar 1.0         60 sec    (it's a new program and I did not perform other tests on it)
  86. StuffIt Deluxe  21 sec
  87. suntar 1.3.3    17 sec
  88. suntar 2.0      17 sec
  89. tar 3.0         12 sec
  90.  
  91. ÑÑÑÑuudecode (ram disk -> hard disk, 900k file)
  92.  
  93. uulite 1.3          300 sec    (what a pity, its user interface is very pretty, but 5 minutes╔)
  94. UMCP¬ Tools          95 sec
  95. tiger             65 sec (ram->ram)  120 sec (HD->HD)
  96. un*files (bug fixed and recompiled with ThC 4)   55 sec (ram->ram) 105 sec (HD->HD)
  97. StuffIt Deluxe    46 sec
  98. suntar 2.0        30 sec
  99. UUParser 1.5      23 sec    (HD->RAM, I could not succeed to decode RAM->HD)
  100. UUtool 2.32       20 sec
  101.  
  102. ÑÑÑÑMacbinary extraction (HD->HD, 900k file)
  103.  
  104. UMCP¬ Tools    100 sec
  105. suntar 1.2.1        96 sec
  106. BinHex 5.0      29 sec
  107. StuffIt Deluxe  24 sec
  108. MacBinary II+   17 sec
  109. suntar 1.3.3    17 sec
  110. suntar 2.0      17 sec
  111. suntar 2.0 (doubling the buffers size) 14 sec
  112. MacBinary 1.01  12 sec
  113.  
  114. ÑÑÑÑtar creation (HD->ram disk, 700k directory)
  115.  
  116. StuffIt Deluxe  28 sec
  117. suntar 2.0      24 sec
  118. tar 3.0         21 sec
  119.  
  120. ÑÑÑÑtar creation (HD->HD, 900k file)
  121.  
  122. StuffIt Deluxe  17 sec
  123. suntar 2.0      16 sec
  124. tar 3.0         12 sec
  125.  
  126. ÑÑÑÑtar creation (HD->floppy disk, 700k directory)
  127.  
  128. suntar 1.1     400 sec
  129. suntar 1.2.1   360 sec
  130. StuffIt Deluxe  (file on a Mac floppy disk) 125 sec
  131. tar 3.0        49 sec
  132. suntar 1.3.3   45 sec        (was buffered only towards the floppy)
  133. suntar 2.0     42 sec
  134.  
  135. ÑÑÑÑBinHex creation (HD->ram, 900k file)
  136.  
  137. StuffIt 1.5.1  128 sec
  138. StuffIt Deluxe 110 sec
  139. Downline       95 sec
  140. BinHex 4.0     92 sec
  141. BinHqx DA      51 sec
  142. Compact Pro    47 sec
  143. suntar 2.0      29 sec
  144.  
  145. ÑÑÑÑMacBinary creation (HD->HD, 900k file)
  146.  
  147. UMCP¬ Tools     100 sec
  148. suntar 2.0 b8   35 sec                (buffered towards the destination but not the source)
  149. BinHex 5.0      29 sec
  150. StuffIt Deluxe  26 sec
  151. MacBinary II+   17 sec
  152. suntar 2.0      15 sec
  153. MacBinary 1.01  13 sec
  154.  
  155. If you are a programmer and you want to write fast code, this is what
  156. I learnt in the process of speeding up suntar:
  157.  
  158. 1) I/O buffering is always essential: I believe that in many categories
  159.    the faster is the program which uses the largest buffer. The large
  160.    jumps in the times (e.g. a factor of 2) between two programs are always
  161.    due to different buffering schemes (e.g.: read one char at a time,
  162.    512 bytes, 8k or more). But there is a point at which increasing the
  163.    buffer gets no increase in speed, which depends on the device: for a
  164.    hard disk 8k is good,  for a floppy disk it's better 9k (that's a
  165.    track or half track on 720k or 1440k floppy disks), and very large
  166.    buffers are still useful for an extraction to the same device if
  167.    the source file and the destination file are placed at different
  168.    positions and a large head movement is required every time the
  169.    application loads or flushes a buffer.
  170. 2) only for complex conversions, at least for operations on fast disks,
  171.    it's important a well optimazed algorithm, where most operations
  172.    are done inside a single loop within a single function, with all
  173.    essential variables kept in registers.
  174. 3) for very simple formats (MacBinary, non-compressed PackIt, tar)
  175.    it's important to handle one format only: suntar suffers from its
  176.    number of supported formats, StuffIt Deluxe suffers even more
  177.    (I mean that it's possible and easy to be 50% faster than suntar
  178.    in uncompressed PackIt extraction, no program does that only
  179.    because the PackIt format is obsolete and the original
  180.    PackIt is outperformed anyway also by non-optimized programs).
  181. 4) only if the algorithm should contain some code written by a
  182.    Mathematician, some knowledge of Mathematics is not bad
  183.    (Mathematicians usually write straighforwardly and never worry
  184.    about speed, but in order to rewrite their code you must understand
  185.    what they're doing).
  186. 5) assembly language is useful, but only in special cases: e.g. mcopy
  187.    is three times faster than a standard memcpy, but it would be almost
  188.    as fast written in C: it's the smart algorithm which makes it fast.
  189.    Assembly language is really essential only if you need instructions
  190.    which the C compiler does not exploit (DBRA, SWAP, BTST, all the
  191.    operations involving the processor flags) or exceptionally when you
  192.    need more register variables than the compiler supports.
  193. 6) never forget to measure the speed and compare it to other programs:
  194.    one may believe to have written a wonderfully fast program and then
  195.    discover that a small detail makes it slow.
  196.  
  197.                             17 October 1993
  198.                             Gabriele Speranza